\chapter{Besluit}
\label{Besluit}

De testsuite werd opnieuw uitgevoerd nadat alle aanpassingen aan Narcissus werden gemaakt. Uit de testresultaten is te zien
dat er geen extra tests falen nadat de aanpassinge aan Narcissus toegepast werden. De testsuite test wel enkel voor standaard JavaScript 
functionaliteiten en niet de functionaliteiten die door de policies afgeschermd kunnen worden.
De effecten van verschillende policies worden dus niet getest, maar de aanpassingen hebben in ieder geval geen nieuwe fouten in Narcissus veroorzaakt.

Dat de gewenste operaties degelijk afgeschermd worden, is getest door een aantal sunny days scenario's te testen voor elke operatie.


\section{Beperkingen}

Een deel van de beperkingen zijn reeds aan bod geokomen in de vorige stukken. 

\subsubsection{Narcissus.interpreter.evaluateURL()}

Deze methode wordt gebruikt om externe JavaScript bestanden in te laden. Zoals in hoofdstuk \ref{Narcissus} te zien was, maakt
deze methode gebruik van het XMLHttpRequest object. Omdat het XHR object beperkt wordt door de same-origin policy is het dus niet
mogelijk om bestanden die van andere origines afkomstig zijn uit te voeren. Er is geen manier om deze beperking te omzeilen via JavaScript
zonder gebruik te maken van een browser addon. Een andere mogelijke oplossing voor dit probleem zou kunnen zijn dat de bestanden 
op de server kunnen gedownload worden door een server-side script dat opgeroepen wordt door Narcissus. 

\pagebreak

\begin{lstlisting}[caption=XHR met server-side script.]
 function evaluateUrl(u, p, f, l){
    //maakt gebruikt van het server-side script op de lokale server
     eval_req.open('GET', 'http://my.origin.com?get_file.php?url=' + u , false); 
     eval_req.send(null);
     if (eval_req.status !== 200) {
        throw new Error("Error loading " + u);
     }
     return evaluate(eval_req.responseText,p,f,l);
  }
\end{lstlisting}

\subsubsection{iFrame}

Zoals eerder vermeld wordt de iframe niet ondersteund. Er zijn twee mogelijke manieren om een iframe te gebruiken. Een iframe kan
ge\"inlined worden als html of er kan een pagina in een iframe geladen worden door gebruik te maken van het frame.src attribuut.

Als er gebruik wordt gemaakt van het frame.src attribuut zijn er opnieuw problemen door de same-origin policy.
Een frame dat een source heeft in een andere origin kan niet aangepast worden in JavaScript. Deze frame kan dan terug code uitvoeren
in SpideMonkey zonder dat de policy er nog invloed op heeft.

Als html ge\"inlined wordt zit de iframe wel in dezelfde origin, hierdoor lijkt het wel mogelijk om deze methode te ondersteunen.
Het prototype ondersteunt deze methode echter nog niet omdat er hier nog andere problemen mee zijn. Het prototype kan inline iframes
nog niet correct parsen, de reden hiervoor is nog niet voldoende onderzocht.

\subsubsection{document.write()}

Deze functie kan enkel nog gebruikt worden om xhtml strict te schrijven naar het document (plaintext wordt ook bezien als xhtml stict).
De functieoproepen worden wel gebufferd totdat er een xhtml strict stuk tekst in de buffer zit. Zo kan een stuk tekst met meerdere write 
operaties geschreven worden.

\medskip
\begin{lstlisting}[caption=Gebufferde document.write()., label=code:buffer]
 //schrijft <p>Hello, world!</p> naar het document
 document.write('<p>');
 document.write('Hello, world!');
 document.write('</p>');
\end{lstlisting}

De reden dat het prototype enkel xhtml strict aanvaard voor de document.write() methode is dat onze implementatie onvolledige tags atlijd
zal afsluiten. Als er niet zou gebufferd worden tot er xhtml sticte tekst geschreven kan worden zou het voorbeeld in listing \ref{code:buffer}
resulteren in twee lege paragrafen met een stuk tekst ertussen.

Een extentie op deze oplossing is om alle niet geschreven document.write() oproepen ook te bufferen tot het document.onload event afgevuurd wordt. 
Dit event wordt enkel afgevuurd als het document volledig klaar is en zullen dus alle mogelijke document.write() oproepen al opgeroepen zijn. 
Deze oplossing is niet perfect omdat de locatie waar er document.write() opgeroepen wordt effect heeft op de resultaat ervan.

\subsubsection{Flash}

Het is ook mogelijk om vanuit Flash JavaScript uit te voeren. De JavaScrit code die door flash uitgevoerd wordt draait in de context
van SpiderMonkey, zo kunnen de policies dus omzeild worden. Er is geen duielike oplossing voor dit probleem
buiten flash volledig te blokkeren.
                  


